(19) 



(12) 



Europaisches 
Patentamt 



European 
Patent Office 



Office europeen 
des brevets 



(11) EP 1 444 242 B1 

EUROPEAN PATENT SPECIFICATION 



(45) Date of publication and mention 
of the grant of the patent: 
07.02.2007 Bulletin 2007/06 

(21) Application number: 02780463.2 

(22) Date of filing: 15.10.2002 



(51) IntCL: 

G06Q 20/00 (2006 01) 

(86) International application number: 
PCT/US2002/032855 

(87) International publication number: 

WO 2003/042225 (22.05.2003 Gazette 2003/21 ) 



(54) SECURE HANDLING OF STORED-VALUE DATA OBJECTS 

SICHERE HANDHABUNG VON GESPEICHERTEN WERTDATEN OBJEKTEN 
MANIPULATION SECURISEE D'OBJETS DE DONNEES A VALEUR STOCKEE 



CD 

CVI 

CVI 



Q. 

LU 



(84) Designated Contracting States: 

AT BE BG CH CY CZ DE DK EE ES Fl FR GB GR 
IE IT LI LU MC NL PT SE SK TR 

(30) Priority: 13.11.2001 US 8174 

(43) Date of publication of application: 
11.08.2004 Bulletin 2004/33 

(60) Divisional application: 
05110957.7/1 632 917 

(73) Proprietor: Ericsson Inc. 
Piano, Texas 75024 (US) 

(72) Inventors: 

• DUTTA, Santanu 
Cary, NC 27513 (US) 

• RYDECK, Nils 
Cary, NC 27511 (US) 

(74) Representative: Lundqvist, Alida Maria Therese et 
al 

Dr. Ludwig Brann Patentbyra AB, 

P.O. Box 171 92 

104 62 Stockholm (SE) 



(56) References cited: 
EP-A- 0 980 052 
WO-A-00/74300 



EP-A-1 132 839 



• KURAMITSU KETAL: "TTP: secure ACID transfer 
protocol for electronic ticket between personal 
tamper-proof devices" COMPUTER SOFTWARE 
AND APPLICATIONS CONFERENCE, 2000. 
COMPSAC 2000. THE 24TH ANNUAL 
INTERNATIONAL TAIPEI, TAIWAN 25-27 OCT. 
2000, LOS ALAMITOS, CA, USA,IEEE COMPUT. 
SOC, US, 25 October 2000 (2000-10-25), pages 
87-92, XP01 0523749 ISBN: 0-7695-0792-1 

• MATSUYAMA K ET AL: "DISTRIBUTED DIGITAL- 
TICKET MANAGEMENT FOR RIGHTS TRADING 
SYSTEM" PROCEEDINGS ACM CONFERENCE 
ON ELECTRONIC COMMERCE, XX, XX, 1999, 
pages 110-118, XP001 1 30642 

• FUJIMURA K ET AL: "Digital-ticket-controlled 
digital ticket circulation" PROCEEDINGS OFTHE 
EIGHTH USENIX SECURITY SYMPOSIUM 
(SECURITY'99), PROCEEDINGS OF 8TH 
SECURITY SYMPOSIUM, WASHINGTON, DC, 
USA, 23-26 AUG. 1999, pages 229-238, 
XP002251321 1999, Berkeley, CA, USA, USENIX 
Assoc, USA 



Note: Within nine months from the publication of the mention of the grant of the European patent, any person may give 
notice to the European Patent Office of opposition to the European patent granted. Notice of opposition shall be filed in 
a written reasoned statement. It shall not be deemed to have been filed until the opposition fee has been paid. (Art. 
99(1) European Patent Convention). 



Printed by Jouve, 75001 PARIS (FR) 



1 



EP 1 444 242 B1 



2 



Description 

BACKGROUND OF THE INVENTION 

[0001] The present invention generally relates to con- 
ducting secure transactions, and particularly relates to 
securely managing wireless device transactions involv- 
ing stored-value data objects. 

[0002] As portable electronic devices become more 
fully integrated into the everyday lives of people, these 
devices will be used in a broader range of transactions. 
For example, one might integrate payment functions into 
a portable communication device such as a cellular tel- 
ephone. A user can then pay for selected goods or serv- 
ices using the phone's payment functions. 
[0003] Security issues complicate using portable de- 
vices in commercial transactions. For example, if the us- 
er's device contains payment information, how is that in- 
formation conveyed to a vendor system in a manner se- 
cure from unwanted eavesdropping or monitoring? In 
general, significant issues arise in providing end-to-end 
security for such transactions. 

[0004] Particular challenges arise in securely deliver- 
ing and retrieving information to and from a portable de- 
vice. The need forsuch delivery and subsequent retrieval 
might arise in the context of delivering a stored-value 
data objectto the device for later redemption by the user. 
Here, the data object might function analogous to a phys- 
ical ticket. Indeed, a vendor might issue an electronic 
ticket or other token for delivery to the user's device for 
subsequent redemption. Upon redemption of the elec- 
tronic ticket, the user gains access to or receives the 
desired goods or service. 

[0005] EP-A-1 132839 describes a prior art system to 
securely manage stored-value data objects comprising 
an issuing system, a security element in a user device 
and a redeeming system. 

[0006] However, the use of electronic tickets or other 
stored-value data objects requires significant security 
provisions throughout the issuing and redeeming proc- 
esses. An approach to securely managing the use of 
stored-value data objects with portable devices requires 
a solution that addresses these and other security con- 
cerns. Yet, any such approach should make the use of 
such data objects relatively convenient and flexible from 
the user's perspective. 

BRIEF SUMMARY OF THE INVENTION 

[0007] The present invention provides methods and 
apparatus for securely managing wireless device trans- 
actions involving the use of stored-value data objects. In 
some embodiments, the stored-value data object func- 
tions as an electronic ticket or token, and methods and 
apparatus are provided for securely issuing, storing, and 
redeeming the electronic ticket. 

[0008] In at least one embodiment, the wireless device 
requests a desired stored-value data object from a ticket 



issuing system. Theticket issuing system ensures secure 
delivery to the requesting device by encrypting the re- 
quested data object using a public key provided by the 
wireless device in association with the request. Only the 
5 requesting wireless device hasthe corresponding private 
key, and thus only that device can decrypt and subse- 
quently use the data object. The wireless device may 
include a security element, which offers tamper-resistant, 
secure decrypting and storage for the data object, and 
10 secure storage of the private key. 

[0009] The ticket issuing system may offer local ac- 
cess, in which case the wireless device might use RF or 
optical (e.g., infrared) signaling to communicate with the 
ticket issuing system. In at least one embodiment, the 
15 ticket issuing system is a remote server or other system 
accessible through the Internet, and the wireless device 
accesses it through a wireless communication network. 
For example, the device might incorporate a RF trans- 
ceiver adapted to communicate with a cellular commu- 
te nication network. Communication between the internet- 
based ticket issuing system and the wireless device 
might use the Wireless Application Protocol (WAP). If 
WAP is used, the wireless device might provide its as- 
sociated public key to the ticket issuing system in a user 
25 certificate, in accordance with WAP Public Key Infra- 
structure (WPKI) methods. 

[0010] After receiving the stored-value data object 
(e.g., electronic ticket) in encrypted form from the ticket 
issuing system, the wireless device transfers the encrypt- 
so ed data object to its security element, which may be in- 
tegrated in the wireless device or removeably connected 
therewith. In any case, the security element provides for 
secure storage of the data object and does not permit 
viewing, retrieving, or otherwise modifying the stored da- 
35 ta object except in accordance with its security rules. As 
noted, the security element also may provide secure stor- 
age of the private key used to decrypt the data object as 
received from the ticket issuing system. Additionally, the 
security element may allow a user of the wireless device 
40 to browse or view selected fields or portions of the stored 
data object, but prevents unauthorized copying of the 
stored data object by not allowing unencrypted access 
to the full data object. 

[001 1 ] Once the security element contains a stored da- 
45 ta object, such as an electronic ticket, the wireless device 
user can redeem the data object for associated goods or 
services at a compatible ticket redeeming system. The 
ticket redeeming system ensures that the data object be- 
ing redeemed is valid, and cooperates with the security 
50 element in the redeeming wireless device to ensure that 
unauthorized copies of the stored data object cannot be 
extracted by eavesdropping on the communication be- 
tween the wireless device and the ticket redeeming sys- 
tem. Further, the security element in the wireless device 
55 ensures that unauthorized copies of the stored-value da- 
ta object are deleted or otherwise not retained. Commu- 
nication between the wireless device and the ticket re- 
deeming system may use RF, infrared, or other wireless 
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signaling. In at least one embodiment, the wireless de- 
vice includes an RF interface, such as a Bluetooth inter- 
face, for communicating with the ticket redeeming sys- 
tem. Communication between the ticket redeeming sys- 
tem and the wireless device may be based on WAP, or 
on other standardized or proprietary protocols. 
[001 2] In at least some embodiments, the wireless de- 
vice initiates redemption of the stored data object by 
sending a redemption request to the ticket redeeming 
system. The wireless device may also provide its asso- 
ciated public key to the ticket redeeming system as part 
of this request. In response, the ticket redeeming system 
sends a certificate containing its associated public key 
to the wireless device. The ticket redeeming system may 
also send a nonce ("number used once") or other gen- 
erated value (e.g. pseudorandom value) to the wireless 
device. 

[0013] The security element encrypts a combination 
of the generated value supplied by the redeeming system 
and the ticket using the public key received from the re- 
deeming system. The wireless device then sends the en- 
crypted data object to the ticket redeeming system using 
whatever protocols are associated with the particular in- 
terface used to communicate with the ticket redeeming 
system. Generally, these protocols should support trans- 
mission verification to insure that the ticket redeeming 
system successfully receives the encrypted data object. 
Upon transmitting the data object to the ticket redeeming 
system, the security element in the wireless device eras- 
es or otherwise clears its stored copy of the data object. 
[0014] The ticket redeeming system decrypts the re- 
ceived data object using a private key corresponding to 
the public key it provided to the wireless device. During 
decryption, the ticket redeeming system separates the 
data object from the nonce and verifies that the data ob- 
ject contains an authentic signature or other marking data 
from a legitimate ticket issuing system, or from a legiti- 
mate ticket redeeming system. If the data object is a mu Iti- 
use object, such as a multi-use electronic ticket, the ticket 
redeeming system alters the data object as required, 
signs it with its own private key, and then returns it in 
encrypted form to the wireless device, where it is decrypt- 
ed and stored in the security element, ready for subse- 
quent redemption. 

[0015] In any case, the ticket redeeming system may 
offer or otherwise enable access to the goods or service 
associated with redeeming the data object, such as by 
opening a gate or by returning a rapid verification token 
(RVT), in exchange of the data object, to the wireless 
device for subsequent use in accessing the goods or 
service. A RVT as defined herein typically comprises a 
different type of information than the data object dis- 
cussed above, and has associated transfer and verifica- 
tion procedures making it amenable to quick verification. 
[0016] A RVT might be used in situations where one 
or more subsequent rapid verifications are desired after 
initial redemption of a stored data object using full secu- 
rity. For example, a ticketed passenger might use his or 



her portable device to perform full redemption of a stored 
electronic ticket at a ticket redeeming system positioned 
in advance of the boarding area. Upon redeeming the 
electronic ticket, the ticket redeeming system returns a 

5 RVT to the passenger's portable device, which may then 
be rapidly verified immediately prior to boarding the air- 
craft. Of course, usage of RVTs extends to a broad range 
of other activities such as enforcing ticketed access at 
sporting events. 

10 [0017] In at least some embodiments, the ticket re- 
deeming system returns a seed value to the wireless de- 
vice, and may optionally return graphical data or pattern 
generating information. The seed value may be a pseu- 
dorandom value. The security element in the wireless 

15 device uses the returned seed value to drive some form 
of pattern or sequence generator. The pattern/sequence 
generator preferably incorporates time-of-day depend- 
ency in its generation function, such that the sequence 
or pattern generated by it depends on both the seed value 

20 and the time-of-day. If a human operator is meant to re- 
deem or authenticate the RVT, the security element can 
generate an authentication pattern or otherwise manip- 
ulate a graphical element that it displays in a manner 
dependent upon the seed value, and on time-of-day if 

25 desired. Thus, only security elements having valid seed 
values are able to presentthe proper pattern or graphical 
manipulation to the verifying human operator at the ver- 
ification instant. 

[0018] Incorporating time-of-day considerations into 

30 sequence/pattern generation functions protects RVT ver- 
ification against replay attacks. In general, the pattern/ 
sequence generator generates the desired pattern or se- 
quence at the time of verification. In so doing, the time- 
of-day used in generation is very close to current time. 

35 For example, the pattern/sequence might be generated 
a half-second before actual verification. Verification 
might then be made to depend on the time-of-generation 
being within a certain window of time. This dependency 
prevents a user from outputting an otherwise valid veri- 

40 fication pattern or sequence for recording and subse- 
quent playback to a verifying system. 
[0019] Where a subsequent automated system is 
meant to verify the RVT, the wireless device may simply 
transmit a verification sequence to the verifying system. 

45 Generally, the verification sequence contains at least one 
pseudorandom element generated in dependence on the 
seed value, and preferably also in dependence on the 
time-of-day. The verifying system receives the verifica- 
tion sequence and checks its validity. It does so by locally 

50 generating the same pseudorandom element or ele- 
ments in the verification sequence, which is feasible be- 
cause the verification system has knowledge of the seed 
value that was transmitted to the wireless device by the 
ticket redeeming system. This seed value is used sys- 

55 tem-wide, that is, it is given to all wireless devices over 
a moderately long pre-determined period of time. The 
period of time may be much longer than the typical user 
delay between redeeming the ticket at the first TRS and 
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subsequently redeeming the RVT. The RVT-checking 
TRS would allow acceptance of both the present and the 
previous period seeds over a relatively brief period fol- 
lowing a seed-change; this would accommodate users 
who obtained their seed just prior to a seed change. 
[0020] If the pseudorandom element is generated in 
dependence of time-of-day as well as the seed value, 
the wireless device may transmit the time-of-day it used 
in generating the pseudorandom element included in its 
verification sequence. The verifying system can use this 
received-time-of-day value and the known seed value to 
generate its own pseudorandom element for comparison 
against the pseudorandom element received from the 
wi re I ess d e vi ce . Fu rth e r, t h e ve rify i n g syste m m ay q u a I if y 
the time-of-day received from the wireless device to 
make sure it is not old (i.e., stale). 
[0021] Alternatively, verifying system may be synchro- 
nized to the same time reference as the wireless device, 
such that the time-of-day maintained by the verifying sys- 
tem closely matches the time-of-day maintained by the 
wireless device. If such synchronization is not desirable, 
the verifying system may allowfora defined time variance 
between it and the wireless device. In any case, the ver- 
ifyi ng system may also use the time-of-day in determi ni ng 
whether a received verification sequence is valid, thus 
preventing a given verification sequence from being cop- 
ied and reused by other wireless devices. 

BRIEF DESCRIPTION OF THE DRAWINGS 

[0022] 

Fig. 1 is a diagram of an exemplary system support- 
ing the secure handling of stored-value data objects 
in accordance with the present invention. 
Fig. 2 is a more detailed diagram of an exemplary 
embodiment of the system of Fig. 1 . 
Fig. 3 is a diagram of exemplary embodiments of the 
ticket issuing system, ticket redeeming system, and 
personal trusted device shown in Figs. 1 and 2. 
Fig. 4 is an exemplary call flow diagram detailing the 
issuance and redemption of electronic tickets or oth- 
er types of stored-value data objects. 
Fig. 5 is a diagram of an exemplary environment suit- 
ed for the use of rapid verification tokens. 
Fig. 6 is a diagram of an exemplary verification dis- 
play associated with a rapid verification token. 

DETAILED DESCRIPTION OF THE INVENTION 

[0023] The present invention provides systems and 
methods enabling certain transactions related to wireless 
e-commerce. The following detailed description and ac- 
companying drawings provides specific, exemplary de- 
tails regarding implementations for at least some embod- 
iments of the present invention. However, the scope of 
the present invention extends well beyond these specific 
details. For example, it should be understood that where 



wireless communication systems are involved, no par- 
ticular wireless communication interface standard is nec- 
essary for practicing the present invention. 
[0024] Moreover, the discussion below refers specifi- 
5 cally to electronic tickets, but this term should be under- 
stood to be a particular embodiment of the more general 
concept of any stored-value data object. Thus, the term 
"electronic ticket" as used herein encompasses other 
stored-value data objects, such as electronic cash, elec- 
ta tronic tokens, and any other data item or object that may 
be used as a medium of exchange in e-commerce, and 
in other for-value transactional activities. 
[0025] Figure 1 illustrates a simplified, exemplary sys- 
tem 10 for practicing one or more embodiments of the 
15 present invention. System 1 0 comprises a ticket issuing 
system (TIS) 12, a ticket redeeming system (TRS) 14, 
and a user device 1 6. In this context, the user device 1 6 
is referred to herein as a "personal trusted device" (PTD) 
16. The PTD 16 contains a security element 20, which 
20 is adapted to act as a trusted agent of the TIS 12 and 
TRS 14 in stored-value data object transactions, such 
that the security element 20 cooperates with the TIS 1 2 
and TRS 14 in securely issuing, storing, and redeeming 
an electronic ticket 1 8. It should be understood that the 
25 PTD 1 6 represents essentially any device type having 
the appropriate wireless communication capabilities. 
Thus, PTD 16 might be an appropriately configured ra- 
diotelephone or other mobile terminal, personal digital 
assistant, hand-held, laptop, other personal computer 
30 device, or other type of electronic device. 

[0026] In managing the secure transfer, handling, and 
redemption of electronic tickets, the systems and proc- 
esses used must ensure reliable and convenient elec- 
tronic ticket generation, issuance, and redemption, which 
35 includes preventing fraud and misuse. In general, theTIS 
12, TRS 14, and security element 20 cooperate to 
achieve the following goals: 

• The ticket recipient must be assured that the ticket 
40 issuer is legitimate. 

• The ticket must be delivered only to the legitimate 
user, i.e., it shall not be possible for a person other 
than the user to receive and make use of the ticket. 

• The ticket must be prevented from copying by the 
45 user, whether such copying might be undertaken le- 
gitimately or fraudulently. 

• The user must be assured that the ticket collector 
(redeeming system) is legitimate. 

• The ticket must be delivered only to the legitimate 
50 ticket collector, i.e., it shall not be possible for an 

entity other than the legitimate ticket collector to re- 
ceive and make use of the ticket. 

• The ticket collector must have a reliable mechanism 
for ensuring that the ticket is legitimate. 

55 • |f the ticket collector returns the ticket to the user, it 
must ensure that the ticket is delivered only to the 
legitimate user, i.e., it shall not be possible for a per- 
son other than the user to receive and make use of 
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the returned ticket. 

[0027] In addition to the above secure handling re- 
quirements, rapid ticket verification is also a requirement 
in many ticketing services. Rapid verification is especially 
advantageous in mass transit systems, sports events, 
concerts, etc. With rapid verification, which is discussed 
in more detail later, there may be a tradeoff between ver- 
ification security and verification speed. In general, the 
concept entails subjecting an electronic ticket to a high 
level of initial security to insure verification, and then pro- 
viding the user with a potentially less secure, short-lived, 
rapid verification object that may be subsequently verified 
more quickly than the original electronic ticket. 
[0028] Figure 2 is a more detailed illustration of an ex- 
emplary embodiment of secure ticket transactions. In this 
instance, the PTD 1 6 may be a mobile terminal or other 
cellular radiotelephone. As such, the PTD 16 wirelessly 
communicates with the TIS 12 by accessing the wireless 
communication network 22, which typically comprises an 
access network (AN) 26 and a core network (CN) 28. 
The wireless communication network 22 provides access 
to the TIS 1 2 via the internet 24 or by some other network 
connection. The wireless communication network 22 
may be any one of a number of standardized network 
implementations, including GSM, CDMA (IS-95, IS- 
2000), TDMA (TIA/EIA-136), wide band CDMA (W-CD- 
MA), GPRS, or othertype of wireless communication net- 
work. 

[0029] Any number of end-to-end protocols may be 
used in supporting ticketing transactions conducted be- 
tween the PTD 16 and the TIS 12. For example, the TIS 
12 may be a WAP-enabled server, thereby allowing 
WAP-enabled PTDs 1 6 to conduct ticketing transactions 
with the TIS 1 2 based on WAP standards in conjunction 
with special MIME types defined for the ticketing mes- 
sages. In particular, the reader is referred to the stand- 
ards document entitled "Wireless Application Protocol 
Public Key Infrastructure Definition," WAP-271-WPKI, 
Version 24-Apr-2001, as promulgated by the WAP Fo- 
rum. Of course, other protocols may be used, and indeed 
numerous open and proprietary protocols are available 
for supporting transactions between the PTD 16 and the 
TIS 12. 

[0030] Moreover, it should be understood that while 
configuring the TIS 12 as an Internet-accessible ticket 
issuing system is attractive in terms of flexibility and broad 
access, the TIS 12 might be implemented as part of the 
wireless communication network 22. For example, the 
TIS 1 2 may be implemented as one of a number of net- 
work entities within the core network 28. In that case, 
some security concerns associated with the TIS 12 are 
eliminated, or at least minimized, but access to the TIS 
1 2 may be more restricted. For example, the TIS 1 2 might 
be accessible only to subscribers of the wireless com- 
munication network 22. 

[0031] Once the PTD 1 6 receives an electronic ticket 
from the TIS 12, it transfers the ticket 18 to its security 



element 20, where it is decrypted and securely held for 
subsequent redemption. To that end, the PTD 1 6 further 
supports wireless communication with the TRS 14 for 
redemption transactions. The TRS 14 may be linked to 

5 other systems via a supporting network 30, and in fact 
may be connected to one or more of the Internet 24, the 
TIS 12, and the wireless communication network 22. 
While notshown, itshould be understood thattheTRSI 4 
may also be linked directly or indirectly to other TRSs 14, 

10 and to other types of equipment associated with ticket 
redemption, and, optionally, may be linked with rapid ver- 
ification systems discussed later herein. 
[0032] Figure 3 provides more detail regarding exem- 
plary embodiments of the TIS 12, the TRS 14, and the 

15 PTD 16. Additionally, Fig. 3 defines exemplary informa- 
tion exchanged between the PTD 1 6 and the TIS 1 2 and 
TRS 14. 

[0033] Specific embodiments of the PTD 16 will vary 
significantly because the term "PTD", as used herein, 
20 encompasses a broad range of device types. In an ex- 
emplary embodiment, the PTD 1 6 comprises afunctional 
element 40 and wireless interfaces 40 and 42, in addition 
to the security element. As used herein, the term "func- 
tional element" essentially describes the whole of the 
25 PTD 16 apart from the security element 20. As will be 
explained later, the PTD 1 6 may use the same wireless 
interface 42 or 44 to communicate with both the TIS 1 2 
and the TRS 1 4, but will oftentimes incorporate separate 
wireless interfaces. Generally, the need for different wire- 
so less interfaces is determined based on whether the TIS 
1 2 and the TRS 14 are both local systems, both remote 
systems, or a mix of remote and local systems. For ex- 
ample, as described earlier, the PTD 1 6 may communi- 
cate with the TIS 12 using WAP services supported by 
35 the wireless communication network 22, while commu- 
nicating with the TRS 14 at a redemption site via a local 
communication link. 

[0034] The characteristics of functional element 40 will 
vary depending upon the nature of the PTD 16. That is, 

40 functional element 40 may be a cellular telephone, a per- 
sonal digital assistant (PDA), or other type of electronic 
device dependent on the intended purpose of the PTD 
1 6 in question. Generally, thefunctional element 40 com- 
prises some type of processor or processors 50, memory 

45 52, a user interface 54 and a real-time clock (RTC) 56. 
Details of the user interface 54 also vary with the intended 
purpose of the PTD 1 6. For example, if the PTD 1 6 is a 
cellular telephone or other mobile terminal, the user in- 
terface 54 typically comprise a display screen, keypad, 

50 and audio input/out systems. Similarly, if the PTD 16 is 
a PDA or other mobile computing device, the user inter- 
face 54 generally includes display and input/output func- 
tions. 

[0035] The security element 20 in the PTD 1 6 may be 
55 implemented in any number of ways. For example, the 
security element 20 may be integrated with the other sys- 
tems of the PTD 1 6, or may be a removable smart card 
orothermodular device. In any case, the security element 
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20 may be implemented as a tamper-resistant secure 
module that provides for highly secure storage of elec- 
tronic tickets and other sensitive data. In an exemplary 
embodiment, the security element 20 comprises a proc- 
essor, or other logic 60, memory 62, and a sequence/ 
pattern generator 64. Functions associated with the se- 
curity element 20 are described in more detail later in 
association with describingtransactionsinvolvingtheTIS 
12andTRS 14. 

[0036] In an exemplary embodiment, the TIS 1 2 com- 
prises a WAP-enabled server, or other network-accessi- 
ble ticket issuing system. In general, the TIS 1 2 includes 
an interface 70 configured for the type of network with 
which the TIS 1 2 communicates. In some embodiments, 
the interface 70 may include wireless communication 
functionality to support local wireless communication 
with PTDs 1 6. The TIS 1 2further comprises a processing/ 
encryption system 72 and memory 74. 
[0037] Similarly, the TRS 14 comprises an interface 
80, a processing system 82 providing encryption and de- 
cryption services, and memory 84. Of course, both the 
TIS 12 and the TRS 14 may be implemented differently 
depending on the specific capabilities and communica- 
tion methods desired. 

[0038] Independent of the above implementation de- 
tails, atypical electronic ticket transaction involves a pur- 
chase request from the PTD 1 6 to the TIS 1 2, and sub- 
sequent delivery of the requested electronic ticket 18 
from the TIS 1 2 to the PTD 1 6. Later, a user of the PTD 
16 presents the electronic ticket 18 to the TRS 14 for 
redemption. A number of mechanisms are used within 
the present invention to ensure end-to-end security for 
issuing, storing, and redeeming electronic tickets (i.e., 
stored-value data objects). 

[0039] Figure 4 illustrates an exemplary call flow that 
might be practiced in one or more embodiments of the 
present invention. The overall set of electronic ticket 
transactions begins with the PTD 16 generating and 
transmitting a purchase request for receipt by the TIS 12. 
A user certificate that includes a public key associated 
with the PTD 16 is transmitted in conjunction with the 
purchase request, or is otherwise made available to the 
TIS 12. The PTD certificate may be a certificate issued 
by the operator of the TIS 12 or an associated system, 
or may come from a trusted third party such as VISA or 
MASTERCARD. In any case, once the TIS 12 is assured 
of payment for the electronic ticket 18, which procedures 
are not germane to the present invention, it generates 
the requested electronic ticket 18. 
[0040] Referring back to Fig. 3 it might be noted that 
the ticket 1 8 may be generated and held in memory 74. 
Once the ticket 1 8 is generated with the desired content 
and signed or otherwise authenticated by the TIS 12, it 
is encrypted using the public key (PTD PuK ) associated 
with the requesting PTD 1 6. Because only the requesting 
PTD 16 has the corresponding private key, only the re- 
questing PTD 1 6 will be able to receive and make use of 
the encrypted ticket 1 8. Thus, at Step A in Fig. 4, the TIS 



1 2 issues the requested electronic ticket 1 8 in encrypted 
format. Note that the ticket 18 consists of data that is 
digitally signed by the TIS 1 2, the digital signature being 
performed by encrypting the ticket data (TICKET_DATA) 
5 with a private key (TIS PrK ) belonging to and securely held 
by the TIS 12. 

[0041] The PTD 16 receives the encrypted ticket 18 
via the wireless interface 42, and may pass the encrypted 
ticket 1 8 directly to the security element 20, or indirectly 

10 through the functional element 40. In one embodiment, 
the TIS 12 sends the encrypted electronic ticket to the 
PTD 16 as a special Multipurpose Internet Mail Extension 
(MIME) type, which message type triggers the transfer 
of the encrypted ticket 18 to the security element 20. In 

15 any case, the security element 20 decrypts the received 
ticket 1 8 using its securely held private key. The security 
element 20 may hold a root certificate (TIS_ROOT_ 
CERT) corresponding to the TIS 1 2, which certificate in- 
cludes the private key needed to decrypt the electronic 

20 ticket 1 8 received from the TIS 1 2. 

[0042] The decrypted ticket 1 8 is held in security ele- 
ment memory 62. It is noteworthy that the security ele- 
ment's fixed, pre-defined input/output functions never 
yield the decrypted electronic ticket 1 8 to the outside 

25 world. Hence, the ticket 1 8 stored in the security element 
20 is inaccessible to would-be copiers, although the se- 
curity element 20 may make selected fields or portions 
of the ticket 1 8 available for browsing by the user of PTD 
16. 

30 [0043] Subsequent to receiving the ticket 1 8 from the 
TIS 12, the user of the PTD 16 presents the electronic 
ticket 1 8 to the TRS 1 4for redemption. Ticket redemption 
typically begins with the PTD 16 issuing a redemption 
request to the TRS 14, which might take the form of a 

35 WAP Session Protocol (WSP) Get request from the PTD 
1 6 to the TIS 1 2, as shown in Fig. 4 by the Get_Service 
message. The above Get message may be issued as a 
result of the user independently navigating to a TIS web- 
site, or by the receipt by the PTD 1 6 of a WAP Push 

40 message issued by the TIS 12, containing the url of the 
TIS 12, and the user selecting the said url on his PTD. 
[0044] As was mentioned early, the PTD 1 6 preferably 
communicates with the TRS 1 4 wirelessly through wire- 
less interface 42 or 44. If the TRS 14 is remote, the PTD 

45 may access it as it would a remote TIS 12 through the 
wireless communication network 22, in which case the 
PTD 16 uses wireless interface 42. If the TRS 14 is local, 
the PTD 1 6 uses wireless interface 44, which may com- 
prise a radio frequency interface, an optical interface, 

50 some combination thereof, or may be based on some 
other wireless technology. Wireless technologies of par- 
ticular interest in this context include Bluetooth and 
802.1 1 wireless networking standards, and additionally 
include the infrared communications standards promul- 

55 gated by the Infrared Data Association (IrDA). Of course, 
it should be understood that communication between the 
PTD 1 6 and the TRS 1 4 might be based on other stand- 
ards, including proprietary communication protocols. 
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[0045] Upon receiving the redemption request from the 
PTD 1 6, the TRS 14 sends a message, B, termed "Re- 
quest To Show Ticket" to the PTD 1 6, which request in- 
cludes a generated value and a certificate (Cert_TRS n+1 ) 
associated with the particular TRS 14. The generated 
value may be a nonce, for example. The certificate trans- 
ferred from the TRS 14 to the PTD 1 6 includes a public 
encryption key (TRS PuK ) associated with the TRS 14. 
[0046] In response, the security element 20 within the 
PTD 16 creates a composite data object, (Nonce, T), 
comprising the received generated value concatenated 
with the electronic ticket 18. This composite data object 
is then digitally signed by the PTD 16 using the private 
key of the PTD 16. Preferably, a standard format such 
as PKCS 7, is used, whereby the certificate containing 
the PTD's public key, Cert_PTD, is appended to the 
signed object. The signed composite data object is then 
encrypted with the public key belonging to the particular 
TRS 14, the said public key being contained in the cer- 
tificate, Cert_TRS n+1 , sent from the TRS 14 to the PTD 
1 6 in message B in the previous step. In this discussion, 
the present TRS 14 is identified by index number (n+1) 
and a previous TRS, for multi-use tickets, by (n). 
[0047] Following encryption of the signed composite 
data object, the PTD 1 6 returns the encrypted composite 
object to the TRS 1 4. For multi-use tickets described be- 
low, the certificate of the previous ticket redeeming sys- 
tem, Cert_TRS n , is also sent as a component of message 
C. The TRS 14 decrypts the received generated value 
and electronic ticket 18 using the corresponding private 
key (TRS PrK ), known only to that TRS 14, and checks 
the authenticity and integrity of the received electronic 
ticket, as well as verifies the returned generated value. 
[0048] In particular, the TRS 14 checks whether the 
received electronic ticket includes an authentic signature 
or other verification information from a legitimate TIS 12 
and/or from another TRS 14, which might have signed a 
multi-use ticket after modifying it, as described below. In 
so checking, the TRS 14 may use a locally stored copy 
of the root certificates of one or more TISs 12 and the 
certificate of the previous TRS received from the PTD 1 6. 
[0049] The TRS 14 may also check the PTD's signa- 
ture on the composite data object returned by the PTD 
1 6 to verify possession by the PTD 1 6 of the private key 
corresponding to the public key contained in the submit- 
ted PTD certificate. 

[0050] If the electronic ticket 1 8 being redeemed at the 
TRS 1 4 is a one-time use ticket, the TRS 1 4 verifies that 
the ticket is valid and provides a signal or other indication 
to an associated system that the presenter of the ticket 
1 8 should be granted access to the goods or service cor- 
responding to the received ticket 1 8, or that a RVT should 
be issued. In conjunction with transmitting the ticket 18 
from the PTD 16 to the TRS 14 in association with its 
redemption, the security element 20 erases the secure 
copy of the ticket 18 that it holds within its memory 62. 
This prevents unauthorized duplicate copies of the ticket 
18 remaining during or after redemption. 



[0051] In some instances, the electronic ticket 18 is a 
multiple use ticket. If so, the TRS 14 may return a re- 
deemed ticket 18'. The redeemed ticket 18' may com- 
prise a "punched", that is, an altered copy of the original 

5 electronic ticket 18. For example, the TRS 14 may modify 
the original electronic ticket 1 8 to show that it has been 
redeemed for the nth time, where n is a number from one 
(1) to the maximum number of times that the ticket 18 
may be used. In returning a multi-use ticket 1 8', the TRS 

10 1 4 may modify the ticket contents to contain an authen- 
tication signature associated with the TRS 1 4, which may 
be used to verify the redeemed ticket 1 8' at subsequent 
verification points. 

[0052] I n some cases, the result of redeeming a ticket 

15 18 will be the issuance of a rapid verification object by 
the TRS 14. The PTD 16 receives the rapid verification 
object, and later uses it to generate a RVT, which may 
be quickly validated, albeit with less security, at a sub- 
sequent verification point. The rapid verification object 

20 sent from the TRS 14 to the PTD 16 itself might comprise 
the RVT, which is presented by the PTD 1 6 at a later 
verification point, but typically, the rapid verification ob- 
ject is a seed value, possibly with other information, from 
which the PTD 1 6 generates a valid RVT. Other informa- 

25 tion sent by the TRS 14 as part of the rapid verification 
object may include image data, image manipulation in- 
formation, user-identifying data, etc. lnanycase,theTRS 
14 might, depending on circumstances, return a re- 
deemed ticket 18', a rapid verification object, neither, or 

so both. 

[0053] The use of RVTs might arise in association with 
tickets 18 issued for sporting events or for use at train 
stations, for example. In this instance, an original elec- 
tronic ticket 18 might be subject to verification at a TRS 

35 14 positioned at an open access area, whereupon the 
TRS 14 returns a rapid verification object to the redeem- 
ing PTD 16, which object, used in generating the RVT, 
may remain valid only for a defined period of time or a 
defined number of subsequent RVT validations. 

40 [0054] Figure 5 illustrates more specifically an envi- 
ronment where RVTs might be useful. One or more TRSs 
14 are available in an open area where users of PTDs 
16 may initially redeem their electronic tickets 18. This 
initial redemption is typically a high security process, for 

45 example, one performed in accordance with the above 
description. The TRSs 14 return rapid verification objects 
to PTDs 16 redeeming valid electronic tickets 18. The 
PTD users may then present RVTs from their PTDs 16 
to gain access to a controlled access area, for example. 

50 Arrangements of this sort are particularly useful in cir- 
cumstances where event attendees or service users ar- 
rive at staggered times in advance of the event or service, 
andthen subsequently queue up at a particular time. One 
might imagine the usefulness of the combination of high 

55 security verification followed by a subsequent lower se- 
curity but faster verification at airport terminals, and at 
other mass transit facilities. 

[0055] RVTs may be verified by rapid verification sys- 
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terns 1 00, but might also be verified by human operators. 
It should be understood that rapid verification systems 
1 00 might simply be implemented as TRSs 1 4 but adopt- 
ing both the secure verification protocols discussed ear- 
lier as well as lower-overhead rapid verification protocols. 
When returning rapid verification information to PTDs 1 6 
from TRSs 1 4, the TRSs 1 4 may include a variety of data 
elements. In exemplary embodiments, the TRS 14 re- 
turns at least a seed value, and may also return visual 
pattern generating information, image information, and 
one or more associated scripts, the use of which infor- 
mation is explained below. 

[0056] In one approach, the TRS 14 returns an image 
and a seed value in encrypted format as the rapid verifi- 
cation object to the PTD 1 6. The security element 20 in 
the PTD 16 includes a sequence/pattern generator 64 
capable of generating pseudorandom sequences, orvis- 
ual pattern information for display on the PTD screen, 
using the returned seed value. Additionally, the se- 
quence/pattern generator 64 may be adapted to generate 
pseudorandom sequences based not only on this re- 
turned seed value, but on the time of day value that might 
be obtained from the real-time clock 56, for example. In 
many instances, the RTC 56 is itself synchronized to an 
overall network time or other referenced time, such as a 
G PS-based reference time. By making the RVT present- 
ed by the PTD 1 6 for verification dependent on time-of- 
day, the ability to fraudulently replay an earlier-generated 
RVT is eliminated. 

[0057] In an exemplary scenario, a time-varying image 
is generated by the security element 20 in the PTD 16 
by one of two approaches. A bit-mapped core image, 
which may be in data-compressed form, is transmitted 
from the TRS 14 to the PTD 16; this image is then ma- 
nipulated by a program (e.g., computer instructions) na- 
tive to the security element 20. This security element pro- 
gram takes as its inputs the output from the sequence/ 
pattern generator 64, and the time time-of-day output or 
derived from the RTC 56. Alternatively, the program for 
creating and manipulatingthetime-varying image is itself 
sent from the TRS 14 to the PTD 16, possibly in com- 
pressed data form. This latter alternative is more suitable 
when the displayed image is an abstract, computer-gen- 
erated pattern. It is noteworthy that the verification image 
displayed by the PTD 16, regardless of how it is gener- 
ated, should have the qualities of easy human recogni- 
tion, including clear discrimination among its various ma- 
nipulated forms. 

[0058] Figure 6 illustrates one embodiment of a hu- 
man-verifiable RVT. The depicted images may be dis- 
played on a display screen included within the user in- 
terface 54 in the PTD 1 6. In this exemplary embodiment, 
the displayed image includes (a)the user's picture, which 
is typically static; (b) a recognizable pattern that changes 
at discrete time intervals; and (c) a recognizable pattern 
changing continuously with time. 
[0059] The user's picture in (a) above is accessed by 
the TRS 14 from a server whose location address, as 



typified by an Internet url, is contained in the PTD certif- 
icate sent by the PTD 1 6 to the TRS 1 4 in message C in 
association with signing the composite data object. This 
image, possibly in compressed form, is forwarded by the 
5 TRS 1 4 to the PTD 1 6 as a part of the rapid verification 
object (RVO) in message D. 

[0060] As an example of (b) and (c), the illustration of 
Fig. 6 shows a wine glass and ball in association with the 
user's image. The wine glass takes on a series of rota- 
te tional angles, wherein the sequence of rotational angles 
assumed by the wine glass are determined by the se- 
quence/pattern generator 64, based on the seed value 
provided by the TRS 14 and a time-of-day value. The 
wine glass image changes at discrete time instants which 
15 are sufficiently spaced to allow easy human verification. 
The exemplary time interval shown in Fig. 6 is 30 sec- 
onds. In this case, the defense against replay attack is 
the presence of the user's picture as a component of the 
verification image displayed by the PTD 16. 
20 [0061] Regarding the image component (c), it may be 
advantageous to pick the ball as following a circular orbit 
in an essentially continuous motion where the direction 
of rotation of the ball is determined by a pseudorandom 
sequence, and the position of the ball in its circular path 
25 is determined by the time-of-day. A continuously varying 
component in the verification image provides a defense 
against replay attacks comprising real time monitoring 
and rebroadcast of the image to multiple fraudulent us- 
ers. 

30 [0062] The human operator may have a rapid verifica- 
tion system 100, such as a hand-held device, having a 
display with similar images following the same pseudor- 
andom sequence or sequences. In this manner, the hu- 
man operator can look at the PTD's display and compare 

35 the verification image depicted there with the reference 
image displayed by the rapid verification system 100. 
[0063] In ensuring that the displayed patterns on the 
rapid verification system 1 00 remain in sync with the pat- 
terns being generated by PTD 1 6 having valid RVTs, the 

40 rapid verification system 100 may synchronize its time 
of day to the same time reference used by the security 
element 20 in the PTD 16. Thus, the rapid verification 
system 1 00 may synchronize its time of day to a network 
time of day, such as the time maintained by the wireless 

45 communication network 22, or may also have a G PS- 
based time reference. Alternatively, the rapid verification 
system 1 00 may simply maintain a very accurate time of 
day, and allow for slight variations between its time of 
day and the times of day in the PTD 16. Thus, slight 

50 discrepancies between the PTD image and the verifica- 
tion image may be tolerated. 

[0064] As mentioned earlier, an alternative approach 
has the PTD 16 provide the time-of-day to the rapid ver- 
ification system 100. This allows the rapid verification 
55 system 1 00 to use the same time-of-day value as was 
used by the security element 20 in generating pseudor- 
andom data from the seed value. With this approach, the 
rapid verification system can determine whetherthetime- 
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of-day value provided by the PTD 16 is recent enough 
to be deemed legitimate. That is, if the time-of-day value 
received from the PTD 1 6 is too old, the rapid verification 
system 100 can reject the verification sequence or pat- 
tern provided to it as being a replay of an earlier verifica- 
tion sequence. 

[0065] Use of a verification sequence is particularly 
well suited where verification is performed using auto- 
mated processing. Thus, the RVT generated by the se- 
curity element 20 and transmitted from the PTD 1 6 to the 
rapid verification system 1 00 might simply be a verifica- 
tion sequence having at least one pseudorandom ele- 
ment generated in dependence on the seed value pro- 
vided by a legitimate TRS 1 4 and a PTD time-of-day. The 
verification sequence can include additional, non-pseu- 
dorandom information, such as protocol-defined head- 
ers, etc. As with the human-readable version, the rapid 
verification system 100 may determine whether a se- 
quence is valid based on the known seed value and a 
synchronized time of day. 

[0066] If the rapid verification system's time of day is 
not synchronized to the same reference used by the se- 
curity element20, rapid verification system 1 00 may com- 
pare the received sequence to one of several valid se- 
quences representing a defined time window. In this mat- 
ter, absolute synchronization of times between PTD 16 
and rapid verification system 100 is not necessary; how- 
ever, by defining the non-discrepancy tolerance to be 
suitably small (e.g., ± 2 seconds), the rapid verification 
system 100 ensures that an earlier issued seed value 
has not been redistributed to another PTD 16 for fraud- 
ulent reuse. 

[0067] As noted in detail above, the PTD 16 may in- 
clude the actual time-of-day value used by the security 
element 20 in generating the pseudorandom element or 
elements as a preamble in the verification sequence it 
transmits to the rapid verification system 1 00. This tech- 
nique is useful in that the rapid verification system's time- 
of-day may not exactly match the time-of-day reference 
used by the security element 20. The rapid verification 
system 100 will check the received verification sequence 
ag ai n st its own ref e rencesequenceforthe PTD - dec I a red 
time-of-day (i.e., for the time-of-day value received from 
the PTD). If the received verification sequence is valid, 
this proves that the PTD 16 (security element 20) had 
the correct seed value. The rapid verification system 1 00 
will then decide if the PTD-declared time-of-day is within 
acceptable limits of clock inaccuracy and processing de- 
lay. Verification sequences reflecting excessive delays 
would be rejected as they might result from replay fraud. 
[0068] In an alternate exemplary approach, the rapid 
verification object returned by the TRS 1 4 is a paper ticket 
or other physical token that may be redeemed by the 
PTD user. In this approach, the TRS 14 may mark the 
physical token with authentication indicia that may 
change with time to prevent token reuse. 
[0069] Given the broad scope of the present invention 
with regard to issuing, managing and redeeming elec- 



tronic tickets or other stored-value data objects within the 
realm of e-commerce or in the context of other types of 
secure transactions, it should be understood that the ex- 
emplary details above are not limiting. 



Claims 

1 . A system (1 0) to securely manage stored-value data 
10 objects, the system comprising: 

an issuing system (12) to issue a stored-value 
data object to a user device (16), wherein the 
issuing system signs the stored-value data ob- 
15 ject and encrypts the stored-value data object 

using a first public key (PTD PuK ) associated with 
the user device; 

a security element (20) comprising a portion of 
the user device (16) to decrypt and securely 
20 store the stored-value data object received at 

the user device from the issuing system (12); 
and 

a redeeming system (14) to redeem the stored- 
value data object by receiving the stored-value 
25 data object from the user device; 

characterized in that the security element (20) en- 
crypts the stored-value data object with a second 
public key (TRS PuK ) received from the redeeming 
30 system and associated with the redeeming system 
(14); 

and wherein the redeeming system (14) decrypts the 
stored-value data object and verifies that the stored- 
value data object was signed by the issuing system 
35 (12). 

2. The system of claim 1 , wherein the security element 
(20) comprises a memory device (62) providing non- 
volatile storage for a first private key (PTD PrK ) cor- 

40 responding to the first public key used by the issuing 
system (12) to encrypt the stored-value data object. 

3. The system of claim 1, wherein the issuing system 
(12) comprises: 

45 

a communication interface (70) to receive 
stored-value data object requests and issue 
stored-value data objects; 
a processing system (72) to sign and encrypt 
50 stored-value data objects; and 

memory (74) to store an issuing system private 
key (TIS PrK ) used in signing stored-value data 
objects. 

55 4. The system of claim 1 , wherein the redeeming sys- 
tem (14) comprises: 

a communication interface (80) to receive re- 
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demption requests and stored-value data ob- 
jects from user devices; 
a processing system (82) to decrypt and verify 
stored-value data objects received from user de- 
vices; and 5 
memory (84) to store a redeeming system pri- 
vate key (TRS PrK ) used in decrypting the re- 
ceived stored-value data objects. 

5. The system of claim 1 further comprising a second 
redeeming system (1 4) to verify a multi-use stored- 
value data object returned to the user device (16) 
from the first redeeming system (14) responsive to 
the user device redeeming the stored-value data ob- 
ject received from the ticket issuing system (12). 

6. The system of claim 1 further comprising a rapid ver- 
ification system (100) to redeem a rapid verification 
token (RVT) generated by the security element (20) 
in the user device (16), and wherein the redeeming 
system (14) is arranged to return a seed value to the 
user device responsive to the user device redeeming 
the stored-value data object at the redeeming sys- 
tem, the said seed value determining at least one 
pseudorandom element of the said RVT. 

7. A user device (16) serving as a secure agent for 
stored-value data object issuing (1 2) and redeeming 
(14) systems, the user device comprising: 

at least one wireless interface (42, 44) to com- 
municate with the issuing and redeeming sys- 
tems; and 

a security element (20) comprising at least one 
processor (60) and associated memory (62) to: 

securely store a first private key (PTD PrK ) 
associated with the security element; 
decrypt a stored-value data object received 
from the issuing system (12) using the first 
private key (PTD PrK ) and securely store the 
decrypted stored-value data object; 

characterized in that the security element (20) is 
further arranged to: 

encrypt the stored-value data object and a gen- 
erated value using a second public key 
(TRS PuK ) associated with the redeeming sys- 
tem (14), wherein the 

second public key (TRS PuK ) and the generated 
value are received from the redeeming system 
(14); 

transfer the encrypted stored-value data object 
and generated value to the redeeming system 
(14); and 

erase the stored-value data object from the as- 
sociated memory (62)in the security element 



(20) responsive to transfer of stored-value data 
object to the redeeming system (14). 

8. The user device of claim 7, wherein the at least one 
wireless interface (42, 44) comprises first and sec- 
ond wireless interfaces and wherein the second wire- 
less interface (44) is a local wireless interface, and 
further wherein the redeeming system (14) is local 
with respect to the user device (16), such that the 
security element (20) and the redeeming system (14) 
communicate via the second wireless interface (44). 

9. The user device of claim 7, wherein the security el- 
ement (20) receives a modified stored-value data 
object from the redeeming system (14) responsive 
to redeeming the stored-value data object, if the 
stored-value data object was a multi-use stored-val- 
ue data object. 

10. The user device of claim 7, wherein the security el- 
ement (20) further comprises a sequence/pattern 
generator (64) to generate at least one pseudoran- 
dom element as part of rapid verification activities 
subsequent to redeeming the stored-value data ob- 
ject at the redeeming system (14). 

11. A method of securely managing the issuance and 
redemption of stored-value data objects, the method 
comprising: 

issuing a stored-value data object from an issu- 
ing system (12) to a user device (16), wherein 
the issuing system en crypts the stored -value da- 
ta object using a first public key (PTD PuK ) asso- 
ciated with the user device and the user device 
(1 6) decrypts the stored-value data object using 
a private key (PTD PrK ) known to the user device; 

characterized by the method further comprising: 

transferring a second public key (TRS PuK ) re- 
ceived from a redeeming system (1 4) and asso- 
ciated with the redeeming system to the user 
device (1 6) responsive to a redemption request; 
receiving the stored-value data object from the 
user device (16) at the redeeming system (14), 
wherein the stored-value data object is encrypt- 
ed by the user device (1 6) using the second pub- 
lic key (TRS PuK ); and 

validating the stored-value data object at the re- 
deeming system (14) after decrypting the 
stored-value data object using a private key 
(TRS PrK ) known to the redeeming system (14). 

12. The method of claim 11 further comprising transfer- 
ring a generated value from the redeeming system 
(14) to the user device (16) responsive to the re- 
demption request. 
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13. The method of claim 12, wherein the user device 
(1 6) uses both the generated value and the second 
public key (TRS PuK ) to encrypt the stored-value data 
object received at the redeeming system (14), and 
wherein the redeeming system validates both the 
stored-value data object and the generated value 
after decrypting the stored-value data object and the 
generated value using private key (TRS PrK ) known 
to the redeeming system (14). 

1 4. The method of claim 1 3, wherein validating the gen- 
erated value and the stored-value data object re- 
turned from the user device (16) to the redeeming 
system (14) comprises verifying that the generated 
value returned from the user device matches the 
generated value sent from the redeeming system to 
the user device. 

1 5. The method of claim 1 3, wherein validating the gen- 
erated value and the stored-value data object re- 
turned from the user device (16) to the redeeming 
system (1 4) comprises verifying that the stored-val- 
ue data object is signed by the issuing system (12). 

16. The method of claim 15, wherein verifying that the 
stored-valued data object is signed by the issuing 
system (12) comprises validating a digital signature 
using a second private key at the redeeming system 
(14), and wherein the second private key is associ- 
ated with the issuing system (12). 

17. The method of claim 15, wherein verifying that the 
stored-valued data object is signed by the issuing 
system (12) comprises validating a digital signature 
using a second private key at the redeeming system 
(14), and wherein the second private key is associ- 
ated with another redeeming system. 

18. The method of claim 12or 13 further comprising gen- 
erating the generated value as a nonce. 

1 9. The method of claim 1 1 further comprising configur- 
ing the issuing system (1 2) as a WAP-enabled serv- 
er, which is also capable of generating and respond- 
ingto special ticketing MIME types, allowingthe user 
device (1 6) to request and receive the stored-value 
data object in accordance with WAP procedures 
complemented with the said MIME types. 

20. The method of claim 1 1 further comprising returning 
a modified stored-value data objectf rom the redeem- 
ing system (1 4) to the user device (1 6) if the stored- 
val ue data object bei ng redeemed by the user device 
(16) is a multi-use stored-value data object. 

21. The method of claim 20 further comprising modifying 
the multi-use stored-value data object received at 
the redeeming system (1 4) from the user device (1 6) 



by setting a redemption counter value in the multi- 
use stored-value data object, wherein the redemp- 
tion counter value comprises a portion of the data 
comprising the stored-value data object. 

5 

22. The method of claim 1 3 further comprising returning 
a seed value to the user device (1 6) if the generated 
value and stored-value data object received from the 
user device (16) are validated. 

10 

23. The method of claim 22 further comprising: 

receiving a verification sequence including afirst 
pseudorandom element at a rapid verification 

15 system (100); 

validating the verification sequence by deter- 
mining whetherthe first pseudorandom element 
matches a second pseudorandom element gen- 
erated by the verification system using the same 

20 seed value; and 

wherein the user device (1 6) generates the first 
pseudorandom element usingthe seed value re- 
ceived from the redeeming system (14). 

25 24. The method of claim 22 further comprising verifying 
by a human operator at a rapid verification point a 
verification image generated by the user device (1 6), 
wherein the verification image is dependent on the 
seed value returned to the user device (16) by the 

30 redeeming system (14). 

25. The method of claim 1 1 further comprising receiving 
thefirst public key (PTD PuK ) atthe redeeming system 
(14). 

35 

26. The method of claim 25 further comprising returning 
a redeemed stored-value data object encrypted us- 
ing the first public key (PTD PuK ) to the user device 
(16) from the redeeming system (14). 

40 

27. The method of claim 26 furthercomprising exchang- 
ing the redeemed stored-value data object for a tem- 
porary stored-value data object that may be subse- 
quently validated on a temporary basis. 

45 

28. The method of claim 25 further comprising returning 
a seed value, encrypted using the first public key 
(PTD PuK ) associated with the user device (1 6), from 
the redeeming system (14) to the user device (16). 

50 

29. The method of claim 28 further comprising verifying 
the temporary stored-value data object, based on 
the seed value, during a subsequent redemption at- 
tempt by the user device (1 6). 

55 

30. The method of claim 29, wherein verifying the tem- 
porary stored-value data object, based on the seed 
value, during a subsequent redemption attempt by 
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the user device (1 6) comprises verifying a pseudor- 
andom number sequence returned from the user de- 
vice (1 6) based on the seed value and a redemption- 
system time-of-day value. 

5 

31. The method of claim 27 further comprising verifying 
the temporary stored-value data object at a second 
redeeming system (1 4) using a reduced-security re- 
demption protocol as compared to the initial verifi- 
cation of the stored-value data object at the first re- 10 
deeming system (14). 



Patentanspriiche 

15 

1. System (1 0)furdiesichere Handhabungvon gespei- 
cherten Wertdatenobjekten, wobei das System auf- 
weist: 

ein Ausgabesystem (1 2) zur Ausgabe eines ge- 20 
speicherten Wertdatenobjektes an eine Benut- 
zervorrichtung (1 6), wobei das Ausgabesystem 
das gespeicherte Wertdatenobjekt signiert und 
das gespeicherte Wertdatenobjekt unter Ver- 
wendung eines ersten allgemeinen Schlussels 25 
(PTD PuK ), welche der Benutzervorrichtung zu- 
geordnet ist, verschlusselt; 
ein Sicherheitselement (20), umfassend einen 
Bereich in der Benutzervorrichtung (16) zum 
Entschlusseln und zum sicheren Speichern des 30 
gespeicherten Wertdatenobjektes, das an der 
Benutzervorrichtung von dem Ausgabesystem 
(12) empfangen wurde; und 
ein Losesystem (14) zum Losen des gespei- 
cherten Wertdatenobjektes, indem das gespei- 35 
cherte Wertdatenobjekt von der Benutzervor- 
richtung empfangen wird; 

dadurch gekennzeichnet, dass das Sicherheits- 
element (20) das gespeicherte Wertdatenobjekt mit 40 
einem zweiten allgemeinen Schlussel (TRS PuK ), der 
von dem Losesystem (1 4) empfangen wird und dem 
Losesystem (14) zugeordnet ist, verschlusselt; 
und wobei das Losesystem (14) das gespeicherte 
Wertdatenobjekt entschlusselt und verifiziert, dass 45 
das gespeicherte Wertdatenobjekt von dem Ausga- 
besystem (12) signiert wurde. 

2. System nach Anspruch 1 , wobei das Sicherheitsele- 
ment (20) eine Speichervorrichtung (62) umfasst, die 50 
ein nicht-fluchtiges Speichern eines ersten person- 
lichen Schlussels (PTD PrK ), der dem ersten allge- 
meinen Schlussel entspricht, der von dem Ausga- 
besystem (12) verwendet wird, ermoglicht, um das 
gespeicherte Datenobjekt zu verschlusseln. 55 

3. System nach Anspruch 1; wobei das Ausgabesy- 
stem (12) umfasst: 



eine Kommunikationsschnittstelle (70) zum 
Empfangen von Anfragen nach gespeicherten 
Wertdatenobjekten und zum Ausgeben von ge- 
speicherten Wertdatenobjekten; 
ein Verarbeitungssystem (72) zum Signieren 
und Verschlusseln von gespeicherten Wertda- 
tenobjekten; und 

einen Speicher (74) zum Speichern eines per- 
sonlichen Ausgabesystemschlussels (TIS PrK ), 
der zum Signieren von gespeicherten Wertda- 
tenobjekten verwendet wird. 

4. System nach Anspruch 1, wobei das Losesystem 
(14) aufweist: 

eine Kommunikationsschnittstelle (18) zum 
Empfangen von Loseanfragen und von gespei- 
cherten Wertdatenobjekten von Benutzervor- 
richtungen; 

ein Verarbeitungssystem (82) zum Entschlus- 
seln und Verifizieren von gespeicherten Wert- 
datenobjekten, die von Benutzereinrichtungen 
empfangen wurden; und 
einen Speicher (84) zum Speichern eines per- 
sonlichen Losesystemschlussels (TRS PrK ), der 
zum Entschlusseln der empfangenen, gespei- 
cherten Wertdatenobjekte verwendet wird. 

5. System nach Anspruch 1 , das ferner ein zweites Lo- 
sesystem (14) aufweist, um ein gespeichertes Mehr- 
zweck-Wertdatenobjekt zu verifizieren, das zu der 
Benutzervorrichtung (16) von dem ersten Losesy- 
stem (1 4) als Antwort auf das Losen des gespeicher- 
ten Wertdatenobjektes, das von dem ersten Ticket- 
ausgabesystem (12) empfangen wurde, durch die 
Benutzervorrichtung zuruckgesendet wurde. 

6. System nach Anspruch 1 , das ferner ein Schnellve- 
rifizierungssystem (1 00) aufweist, um ein Schnellve- 
rifizierungsmittel (RVT), das durch das Sicherheits- 
element (20) in der Benutzervorrichtung (16) erzeugt 
wurde, zu losen, und wobei das Losesystem (14) 
angeordnet ist, um einen Seed-Wert an die Benut- 
zervorrichtung als Antwort auf das Losen des ge- 
speicherten Wertdatenobjektes an dem Losesystem 
durch die Benutzervorrichtung zuruckzusenden, wo- 
bei der Seed-Wert wenigstens ein pseudo-zufalliges 
Element des RVT bestimmt. 

7. Benutzervorrichtung (1 6), die als ein Sicherheitsmit- 
tel fur Systeme zur Ausgabe (12) und zum Losen 
(14) von gespeicherten Wertdatenobjekten dient, 
wobei die Benutzervorrichtung aufweist: 

wenigstens eine drahtlose Schnittstelle (42, 44), 
um mit den Ausgabe- und Losesystemen zu 
kommunizieren; und 

ein Sicherheitselement (20), das wenigstens ei- 
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nen Prozessor (60) und einen zugeordneten 
Speicher (62) aufweist, um: 

einen ersten personlichen Schlussel 
(PTD PrK ), der dem Sicherheitselement 5 
zugeordnet ist, sicher zu speichern; 
ein gespeichertes Wertdatenobjekt, das 
von dem Ausgabesystem (12) empfangen 
wird, unter Verwendung des ersten person- 
lichen Schlussels (PTD PrK ) zu entschlus- 10 
seln; und um das entschlusselte, gespei- 
cherte Wertdatenobjekt sicher zu spei- 
chern; 

dadurch gekennzeichnet, dass das Sicherheits- is 
element (20) ferner angeordnet ist, um: 

das gespeicherte Wertdatenobjekt und einen er- 
zeugten Wert unter Verwendung eines zweiten 
allgemeinen Schlussels (TRS PuK ), der dem L6- 20 
sesystem (14) zugeordnet ist, zu entschlusseln, 
wobei der zweite allgemeine Schlussel 
(TRS PuK ) und der zweite Wert von dem Lose- 
system (14) empfangen werden; 
das verse hi usselte, gespeicherte Wertdatenob- 25 
jekt und den erzeugten Wert zu dem Losesy- 
stem (14) zu transferieren; und 
das gespeicherte Wertdatenobjekt aus dem zu- 
geordneten Speicher (62) in dem Sicherheits- 
element (20) als Antwort auf den Transfer des so 
gespeicherten Wertdatenobjektes zu dem L6- 
sesystem (14) zu loschen. 

8. Benutzervorrichtung nach Anspruch 7, wobei die 
wenigstens eine drahtlose Schnittstelle (42, 44) er- 35 
ste und zweite drahtlose Schnittstellen umfasst, und 
wobei die zweite drahtlose Schnittstelle (44) eine lo- 
kale drahtlose Schnittstelle ist, und wobei ferner das 
Losesystem (14) in Bezug auf die Benutzervorrich- 
tung (16) lokal ist, so dass das Sicherheitselement 40 
(20) und das Losesystem (1 4) liber die zweite draht- 
lose Schnittstelle (44) miteinander kommunizieren. 

9. Benutzervorrichtung nach Anspruch 7, wobei das Si- 
cherheitselement (20) ein modifiziertes, gespeicher- 45 
tes Wertdatenobjekt von dem Losesystem (14) als 
Antwort auf das Losen des gespeicherten Wertda- 
tenobjektes empfangt, wenn das gespeicherte Wert- 
datenobjekt ein gespeichertes Mehrzweck-Wertda- 
tenobjekt war. 50 

1 0. Benutzervorrichtung nach Anspruch 7, wobei das Si- 
cherheitselement (20) ferner einen Sequenz/Mu- 
stergenerator (64) umfasst, um wenigstens ein 
pseudo-zufalliges Element als ein Teil der Schnell- 55 
verifizierungsaktivitaten folgend auf das Losen des 
gespeicherten Wertdatenobjektes an dem Losesy- 
stem (14) zu erzeugen. 



11. Verfahren zum sicheren Handhaben der Ausgabe 
und des Losens von gespeicherten Wertdatenobjek- 
ten, wobei das Verfahren die Schritte aufweist: 

Ausgeben eines gespeicherten Wertdatenob- 
jektes von einem Ausgabesystem (12) an eine 
Benutzervorrichtung (16), wobei das Ausgabe- 
system das gespeicherte Wertdatenobjekt unter 
Verwendung eines ersten allgemeinen Schlus- 
sels (PTD PuK ), welcher der Benutzervorrichtung 
zugeordnet ist, verschlusselt, und die Benutzer- 
vorrichtung (16) das gespeicherte Wertdaten- 
objekt unter Verwendung eines personlichen 
Schlussels (PTD PrK ), welcher der Benutzervor- 
richtung bekannt ist, entschlusselt; 

dadurch gekennzeichnet, dass das Verfahren fer- 
ner die Schritte aufweist: 

Transferieren eines zweiten allgemeinen 
Schlussels (TRS PuK ), der von einem Losesy- 
stem (14) empfangen wurde und dem Losesy- 
stem zugeordnet ist, an die Benutzervorrichtung 
(16) als Antwort auf eine Loseanfrage; 
Empfangen des gespeicherten Wertdatenob- 
jektes von der Benutzervorrichtung (1 6) an dem 
Losesystem (1 4), wobei das gespeicherte Wert- 
datenobjekt durch die Benutzervorrichtung (16) 
unter Verwendung des zweiten allgemeinen 
Schlussels (TRS PuK ) verschlusselt wird; und 
Validieren des gespeicherten Wertdatenobjek- 
tes an dem Losesystem (14) nach dem Ent- 
schlusseln des gespeicherten Wertdatenobjek- 
tes unter Verwendung eines personlichen 
Schlussels (TRS PrK ), der dem Losesystem (14) 
bekannt ist. 

1 2. Verfahren nach Anspruch 1 1 , das ferner das Trans- 
ferieren eines erzeugten Wertes von dem Losesy- 
stem (14) zu der Benutzervorrichtung (16) als Ant- 
wort auf die Loseanfrage transferiert. 

13. Verfahren nach Anspruch 12, wobei die Benutzer- 
vorrichtung (16) sowohl den generierten Wert als 
auch den zweiten allgemeinen Schlussel (TRS PuK ) 
zum Verschlusseln des gespeicherten Wertdaten- 
objektes verwendet, das an dem Losesystem (14) 
empfangen wurde, und wobei das Losesystem so- 
wohl das gespeicherte Wertdatenobjekt als auch 
den generierten Wert nach dem Entschlusseln des 
gespeicherten Wertdatenobjektes und des generier- 
ten Wertes unter Verwendung eines personlichen 
Schlussels (TRS PrK ), der dem Losesystem (14) be- 
kannt ist, validiert. 

14. Verfahren nach Anspruch 13, wobei das Validieren 
des generierten Wertes und des gespeicherten 
Wertdatenobjektes, das von der Benutzervorrich- 
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tung (16) an das Losesystem (14) zuruckgesendet 
wurde, das Verifizieren umfasst, dass dergenerierte 
Wert, der von der Henutzervorrichtung zuruckge- 
sendet wurde, mit dem generierten Wert, der von 
dem Losesystem zu der Benutzervorrichtung gesen- 5 
det wurde, ubereinstimmt. 

15. Verfahren nach Anspruch 13, wobei das validieren 
des generierten Wertes und des gespeicherten 
Wertdatenobjektes, das von der Benutzervorrich- 10 
tung (16) zu dem Losesystem (14) zuruckgesendet 
wurde, das Verifizieren aufweist, dass das gespei- 
cherte Wertdatenobjekt durch das Ausgabesystem 
(12) signiert wurde. 

15 

16. Verfahren nach Anspruch 15, wobei das Verifizieren, 
dass das gespeicherte Wertdatenobjekt durch das 
Ausgabesystem (12) signiert ist, das Validieren einer 
digitalen Signatur unter Verwendung eines zweiten 
personlichen Schlussels an dem Losesystem (14) 20 
aufweist, und wobei der zweite personliche Schlus- 

sel dem Ausgabesystem (12) zugeordnet ist. 

17. Verfahren nach Anspruch 15, wobei das Verifizieren, 
dass das gespeicherte Wertdatenobjekt durch das 25 
Ausgabesystem (12) signiert ist, das Validieren einer 
digitalen Signatur unter Verwendung eines zweiten 
personlichen Schlussels an dem Losesystem (14) 
aufweist, und wobei der zweite personliche Schlus- 

sel dem anderen Losesystem zugeordnet ist. 30 

18. Verfahren nach Anspruch 12 oder 13, dasfernerdas 
Generieren des generierten Wertes als eine Nonce 
umfasst. 

35 

19. Verfahren nach Anspruch 1 1 , das ferner das Konfi- 
gurieren des Ausgabesystems (12) als ein WAP-ak- 
tiver Server aufweist, der auch zum Generieren und 
Antworten auf spezielle Ticketing-MIME-Arten ge- 
eignet ist, so dass es der Benutzervorrichtung (16) 40 
moglich ist, das gespeicherte Wertdatenobjekt in 
Ubereinstimmung mit WAP-Verfahren, die mit den 
MIME-Arten erganzt werden, abzufragen und zu 
empfangen. 

45 

20. Verfahren nach Anspruch 1 1 , dasfernerdas Zuruck- 
senden eines modifizierten, gespeicherten Wertda- 
tenobjektes von dem Losesystem (14) an die Benut- 
zervorrichtung (1 6) aufweist, wenn das gespeicherte 
Wertdatenobjekt, das von der Benutzervorrichtung 50 
(16) gelost wird, ein gespeichertes Mehrzweck- 
Wertdatenobjekt ist. 

21. Verfahren nach Anspruch 20, das ferner das Modi- 
fizieren des gespeicherten M e h rzwec k- Wert date n- 55 
objektes, das an dem Losesystem (14) von der Be- 
nutzervorrichtung (16) empfangen wurde, aufweist, 
indem ein Lose-Zahlwert in dem gespeicherten 



M eh rzwec k-Wertd ate nobjekt gesetzt wird, wobei 
der Lose-Zahlwert einen Bereich derDaten aufweist, 
die das gespeicherte Wertdatenobjekt umfassen. 

22. Verfahren nach Anspruch 13, dass ferner das Zu- 
rucksenden eines Seed-Wertes an die Benutzervor- 
richtung (1 6) aufweist, wenn dergenerierte Wert und 
das gespeicherte Wertdatenobjekt, das von der Be- 
nutzervorrichtung (16) empfangen wurde, validiert 
sind. 

23. Verfahren nach Anspruch 22, das ferner die Schritte 
aufweist: 

Empfangen einer Verifizierungssequenz, die 
ein erstes pseudo-zufalliges Element aufweist, 
an einem Schnellverifizierungssystem (100); 
Validieren der Verifizierungssequenz, indem 
bestimmt wird, ob das erste pseudo-zufallige 
Element mit einem zweiten pseudo-zufalligen 
Element, das durch das Verifizierungssystem 
unter Verwendung desselben Seed-Wertes ge- 
neriert wurde, ubereinstimmt; und 
wobei die Benutzervorrichtung (16) das erste 
pseudo-zufallige Element unter Verwendung 
des Seed-Wertes erzeugt, der von dem Lose- 
system (14) empfangen wurde. 

24. Verfahren nach Anspruch 22, das ferner das Verifi- 
zieren eines durch die Benutzervorrichtung (16) ge- 
nerierten Verifizierungsbildes durch einen mensch- 
lichen Operator an einem Schnellverifizierungs- 
punkt aufweist, wobei das Verifizierungsbild von 
dem Seed-Wert, derzu der Benutzervorrichtung (16) 
durch das Losesystem (14) zuruckgesendet wurde, 
abhangig ist. 

25. Verfahren nach Anspruch 11, das ferner das Emp- 
fangen des ersten allgemeinen Schlussels (PTD PuK ) 
an dem Losesystem (14) aufweist. 

26. Verfahren nach Anspruch 25, dasferner daszuruck- 
senden eines gelosten, gespeicherten Wertdaten- 
objektes, das unter Verwendung des ersten allge- 
meinen Schlussels (PTD PuK ) verschlusselt wurde, 
an die Benutzervorrichtung (16) von dem Losesy- 
stem (14) aufweist. 

27. Verfahren nach Anspruch 26, das ferner das Aus- 
tauschen des gelosten, gespeicherten Wertdaten- 
objektes durch ein temporar gespeichertes Wertda- 
tenobjekt aufweist, das anschlieBend auf einer tem- 
poraren Basis validiert werden kann. 

28. Verfahren nach Anspruch 25, dasfernerdas Zuruck- 
senden eines Seed-Wertes, der unter Verwendung 
des ersten allgemeinen Schlussels (PTD PuK ), wel- 
che der Benutzervorrichtung (16) zugeordnet ist, 
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verschlusselt wurde, von dem Losesystem (14) zu 
der Benutzervorrichtung (16) aufweist. 

29. Verfahren nach Anspruch 28, das ferner das Verifi- 
zieren destemporargespeicherten Wertdatenobjek- 
tes, das auf dem Seed-Wert basiert, wahrend eines 
darauf folgenden Loseversuchs durch die Benutzer- 
vorrichtung (16) aufweist. 

30. Verfahren nach Anspruch 29, wobei das Verifizieren 
des temporar gespeicherten Wertdatenobjektes, 
das auf dem Seed-Wert basiert, wahrend eines dar- 
auf folgenden Loseversuchs durch die Benutzervor- 
richtung (16) das Verifizieren einer pseudo-zufalli- 
gen Laufnummer, die von der Benutzervorrichtung 
(1 6) basierend auf dem Seed-Wert und einem Lose- 
System-Tageszeitwert zuruckgesendet wurde, auf- 
weist. 

31. Verfahren nach Anspruch 27, das ferner das Verifi- 
zieren destemporargespeicherten Wertdatenohjek- 
tes an einem zweiten Losesystem (14) unter Ver- 
wendung eines Loseprotokolls mit reduzierter Si- 
cherheit, verglichenmitderAnfangsverifizierungdes 
gespeicherten Wertdatenobjektes an dem ersten 
Losesystem (14) aufweist. 



Revendi cations 

1. systeme (1 0) pour gerer de maniere securisee des 
objets de donnees a valeur stockee, le systeme 
comprenant : 

un systeme de delivrance (12) pour delivrer un 
objet a valeur stockee a un dispositif d'utilisateur 
(1 6), dans lequel le systeme de delivrance signe 
I'objet de donnees a valeur stockee et chiffre 
I'objet de donnees a valeur stockee en utilisant 
une premiere cle publique (PTD PuK ) associee 
au dispositif d'utilisateur; 
un element de securite (20) comprenant une 
partie du dispositif d'utilisateur (1 6) pour dechif- 
frer et stocker de maniere securisee I'objet de 
donnees a valeurstockee recu au dispositif d'uti- 
lisateur a partirdu systeme de delivrance (12); et 
un systeme de rachat (14) pour racheter I'objet 
de donnees a valeurstockee en recevant I'objet 
de donnees a valeurstockee a partir du dispositif 
d'utilisateur; 

caracterise en ce que I'element de securite (20) 
chiffre I'objet de donnees a valeur stockee avec une 
seconde cle publique (TRS PuK ) recue du systeme 
de rachat et associee au systeme de rachat (14); 
et le systeme de rachat (1 4) dechiffre I'objet de don- 
nees a valeur stockee et verifie que I'objet de don- 
nees a valeur stockee a ete signe par le systeme de 



delivrance (12). 

2. Systeme selon la revendication 1 , dans lequel I'ele- 
ment de securite (20) comprend un dispositif de me- 

5 moire (62) procurant un stockage non volatil pour 
une premiere cle privee (PTD PrK ) correspondant a 
la premiere cle publique utilisee par le systeme de 
delivrance (1 2) pour chiffrer I'objet de donnees a va- 
leur stockee. 

10 

3. Systeme selon la revendication 1 , dans lequel le sys- 
teme de delivrance (12) comprend : 

une interface de communication (70) pour rece- 
15 voir des demandes d'objets de donnees a valeur 

stockee et pour delivrer des objets de donnees 
a valeur stockee; 

un systeme de traitement (72) pour signer et 
chiffrer des objets de donnees a valeurstockee; 
20 et 

une memoire (74) pour stocker une cle privee 
de systeme de delivrance (TIS PrK ) utilisee pour 
signer des objets de donnees a valeurstockee. 

25 4. Systeme selon la revendication 1 , dans lequel le sys- 
teme de rachat (14) comprend : 

une interface de communication (80) pour rece- 
voir des demandes de rachat et des objets de 
30 donnees a valeur stockee provenant de dispo- 

sitifs d'utilisateur; 

un systeme de traitement (82) pour dechiffre r et 
verifier des objets de donnees a valeur stockee 
recus de dispositifs d'utilisateur; et 
35 une memoire (84) pour stocker une cle privee 

de systeme de rachat (TRS PrK ) utilisee dans le 
dechiffrement des objets de donnees a valeur 
stockee recus. 

40 5. Systeme selon la revendication 1 , comprenant en 
outre un second systeme de rachat (1 4) pour verifier 
un objet de donnees a valeur stockee multi-usage 
retourne vers le dispositif d'utilisateur (16) a partir 
du premier systeme de rachat (14) en reponse a la 

45 restitution par le dispositif d'utilisateur de I'objet de 
donnees a valeur stockee recu du systeme de deli- 
vrance de tickets (12). 

6. Systeme selon la revendication 1, comprenant en 
50 outre un systeme de verification rapide (100) pour 
racheter unjetonde verification rapide (RVT) gen ere 
par I'element de securite (20) dans le dispositif d'uti- 
lisateur (16), et dans lequel le systeme de rachat 
(14) est agence pour retourner une valeur de graine 
55 au dispositif d'utilisateur en reponse a la restitution 
par le dispositif d'utilisateur de I'objet de donnees a 
valeur stockee, au systeme de rachat, ladite valeur 
de graine determinant au moins un element pseudo- 
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aleatoire dudit RVT. 

7. Dispositif d'utilisateur (16) remplissant la fonction 
d'un agent securise pour des systemes de delivran- 
ce (1 2) et de rachat (1 4) d'objets de donnees a valeur 
stockee, le dispositif d'utilisateur comprenant : 

au moins une interface sans fil (42, 44) pour 
communiquer avec les systemes de delivrance 
et de rachat; et 

un element de securite (20) comprenant au 
moins un processeur (60) et une memoire (62) 
associee pour : 

stockerde maniere securisee une premiere 
cle privee (PTD PrK ) associee a I'element de 
securite; 

dechiffrer un objet de donnees a valeur 
stockee recu du systeme de delivrance 
(12), en utilisant la premiere cle privee 
(PTD PrK ), et stocker de maniere securisee 
I'objet de donnees a valeur stockee dechif- 
fre; 

caracterise en ce que I'element de securite (20) 
est en outre agence pour : 

chiffrer I'objet de donnees a valeur stockee et 
une valeur generee en utilisant une seconde cle 
publique (TRS PuK ) associee au systeme de ra- 
chat (14), la seconde cle publique (TRS PuK ) et 
la valeur generee etant recues du systeme de 
rachat (14); 

transferer vers le systeme de rachat (14) I'objet 
de donnees a valeur stockee et la valeur gene- 
ree ch iff res; et 

effacer I'objet de donnees a valeur stockee de 
la memoire (62) associee dans I'element de se- 
curite (20), en reponse au transfert de I'objet de 
donnees a valeur stockee vers le systeme de 
rachat (14). 

8. Dispositif d'utilisateur selon la revendication 7, dans 
lequel I'au moins une interface sans fil (42, 44) com- 
prend des premiere et seconde interfaces sans fil, 
et dans lequel la seconde interface sans fil (44) est 
une interface sans fil locale, et en outre dans lequel 
le systeme de rachat (14) est local vis-a-vis du dis- 
positif d'utilisateur (16), de facon que I'element de 
securite (20) et le systeme de rachat (14) communi- 
quent par I'intermediaire de la seconde interface 
sans fil (44). 

9. Dispositif d'utilisateur selon la revendication 7, dans 
lequel I'element de securite (20) recoit un objet de 
donnees a valeur stockee modifie provenantdu sys- 
teme de rachat (14), en reponse au rachat de I'objet 
de donnees a valeur stockee, si I'objet de donnees 



a valeur stockee etait un objet de donnees a valeur 
stockee multi-usage. 

10. Dispositif d'utilisateur selon la revendication 7, dans 
5 lequel I'element de securite (20) comprend en outre 

un generateurde sequence /configuration (64) pour 
generer au moins un element pseudo-aleatoire dans 
le cadre d'activites de verification rapide a la suite 
du rachat de I'objet de donnees a valeur stockee au 
systeme de rachat (14). 

11. Procede pour gerer de maniere securisee la deli- 
vrance et le rachat d'objets de donnees a valeur stoc- 
kee, le procede comprenant : 

la delivrance a un dispositif d'utilisateur (1 6) d'un 
objet de donnees a valeur stockee provenant 
d'un systeme de delivrance (12), le systeme de 
delivrance chiffrant I'objet de donnees a valeur 
stockee en utilisant une premiere cle publique 
(PTD PuK ) associee au dispositif d'utilisateur, et 
le dispositif d'utilisateur (16) dechiffrant I'objet 
de donnees a valeur stockee en utilisant une cle 
privee (PTD PrK ) connue du dispositif d'utilisa- 
teur; 

caracterise en ce que le procede comprend en 
outre: 

le transfert vers le dispositif d'utilisateur (16) 
d'une secondecle publique (TRS PuK ) recued'un 
systeme de rachat (14) et associee au systeme 
de rachat, en reponse a une demande de rachat; 
la reception au systeme de rachat (1 4) de I'objet 
de donnees a valeur stockee provenant du dis- 
positif d'utilisateur (1 6), I'objet de donnees a va- 
leur stockee etant chiffre par le dispositif d'utili- 
sateur (16) en utilisant la seconde cle publique 
(TRS PuK ); et 

la validation de I'objet de donnees a valeur stoc- 
kee, au systeme de rachat (1 4), apres le dechif- 
frement de I'objet de donnees a valeur stockee 
en utilisant une cle privee (TRS PrK ) connue du 
systeme de rachat (14). 

12. Procede selon la revendication 11, comprenant en 
outre le transfert vers le dispositif d'utilisateur (16) 
d'une valeur generee provenant du systeme de ra- 
chat (14), en reponse a la demande de rachat. 

13. Procede selon la revendication 12, dans lequel le 
dispositif d'utilisateur (16) utilise a la fois la valeur 
generee et la seconde cle publique (TRS PuK ) pour 
chiffrer I'objet de donnees a valeur stockee recu au 
systeme de rachat (14), et dans lequel le systeme 
de rachat valide a la fois I'objet de donnees a valeurs 
stockee et la valeur generee apres avoir dechiffre 
I'objet de donnees a valeur stockee et la valeur ge- 
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neree en utilisant une cle privee (TRS PrK ) connue 
du systeme de rachat (14). 

14. Procede selon la revendication 13, dans lequel la 
validation de la valeur generee et de I'objet de don- 
nees a valeur stockee retournes du dispositif d'utili- 
sateur (16) au systeme de rachat (14) comprend la 
verification du fait que la valeur generee retournee 
du dispositif d'utilisateur concorde avec la valeur ge- 
neree envoyee du systeme de rachat au dispositif 
d'utilisateur. 

15. Procede selon 1a revendication 13, dans lequel la 
validation de la valeur generee et de I'objet de don- 
nees a valeur stockee retournes du dispositif d'utili- 
sateur (16) au systeme de rachat (14) comprend la 
verification du fait que I'objet de donnees a valeur 
stockee est signe par le systeme de delivrance (1 2). 

16. Procede selon la revendication 15, dans lequel la 
verification du fait que I'objet de donnees a valeur 
stockee est signe par le systeme de delivrance (12) 
comprend la validation d'une signature numerique 
en utilisant une seconde cle privee au systeme de 
rachat (1 4), et dans lequel la seconde cle privee est 
associee au systeme de delivrance (12). 

17. Procede selon la revendication 15, dans lequel la 
verification du fait que I'objet de donnees a valeur 
stockee est signe par le systeme de delivrance (12) 
comprend la validation d'une signature numerique 
en utilisant une seconde cle privee au systeme de 
rachat (1 4), et dans lequel la seconde cle privee est 
associee a un autre systeme de rachat. 

18. Procede selon la revendication 12 ou 13, compre- 
nant en outre la generation de la valeur generee 
comme une valeur prevue pour une utilisation uni- 
que. 

19. Procede selon la revendication 11, comprenant en 
outre la configuration du systeme de delivrance (12) 
comme un serveur ayant une capacite WAP, qui est 
egalement capable de generer des types MIME spe- 
ciaux pour remission de tickets, ainsi que de reagir 
a ces types, permettant au dispositif d'utilisateur (1 6) 
de demander et de recevoir I'objet de donnees a 
valeur stockee conformement a des procedures 
WAP completees par lesdits types MIME. 

20. Procede selon la revendication 11, comprenant en 
outre le retour d'un objet de donnees a valeur stoc- 
kee modifie, du systeme de rachat (14) vers le dis- 
positif d'utilisateur (1 6), si I'objetde donnees a valeur 
stockee dont le rachat est demande par le dispositif 
d'utilisateur (16) est un objet de donnees a valeur 
stockee multi-usage. 



21. Procede selon la revendication 20, comprenant en 
outre la modification de I'objet de donnees a valeur 
stockee multi-usage recu au systeme de rachat (14) 
a partir du dispositif d'utilisateur (16), en fixant une 

5 valeur de compteur de rachat dans I'objet de don- 
nees a valeur stockee multi-usage, dans lequel la 
valeur de compteur de rachat comprend une partie 
des donnees constituant I'objet de donnees a valeur 
stockee. 

10 

22. Procede selon la revendication 13, comprenant en 
outre le retour d'une valeur de graine au dispositif 
d'utilisateur (16) si la valeur generee et I'objet de 
donnees a valeur stockee recus du dispositif d'utili- 

15 sateur (16) sont valides. 

23. Procede selon la revendication 22, comprenant en 
outre les etapes suivantes : 

20 recevoir a un systeme de verification rapide 

(100) une sequence de verification incluant un 
premier element pseudo-aleatoire; 
valider la sequence de verification en determi- 
nants! le premierelement pseudo-aleatoire con- 
25 corde avec un second element pseudo-aleatoire 

genere par le systeme de verification en utilisant 
la meme valeur de graine; et 
dans lequel le dispositif d'utilisateur (16) genere 
le premier element pseudo-aleatoire en utilisant 
30 la valeur de graine recue du systeme de rachat 

(14). 

24. Procede selon la revendication 22, comprenant en 
outre la verification par un operateur humain, a un 

35 point de verification rapide, d'une image de verifica- 
tion generee par le dispositif d'utilisateur (16), dans 
lequel I'image de verification depend de la valeur de 
graine retournee au dispositif d'utilisateur (1 6) par le 
systeme de rachat (14). 

40 

25. Procede selon la revendication 1 1 , comprenant en 
outre la reception de la premiere cle publique 
(PTD PuK ) au systeme de rachat (14). 

45 26. Procede selon la revendication 25, comprenant en 
outre le retour au dispositif d'utilisateur (1 6), a partir 
du systeme de rachat (1 4), d'un objet de donnees a 
valeur stockee rachete, ch iff re en utilisant la premie- 
re cle publique (PTD PuK ) 

50 

27. Procede selon la revendication 26, comprenant en 
outre I'echange de I'objet de donnees a valeur stoc- 
kee rachete contre un objet de donnees a valeur 
stockee temporaire qui peut ensuite etre valide sur 

55 une base temporaire. 

28. Procede selon la revendication 25, comprenant en 
outre le retour au dispositif d'utilisateur (1 6), a partir 
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du systeme de rachat (14), d'une valeur de graine 
chiffree en utilisant la premiere cle publique 
(PTD PuK ) associee au dispositif d'utilisateur (16). 

29. Procede selon la revendication 28, comprenant en 5 
outre la verification de I'objet de donnees a valeur 
stockee temporal re, sur la base de la valeur de grai- 
ne, pendant une tentative de rachat ulterieure effec- 
tuee par le dispositif d'utilisateur (16). 

10 

30. Procede selon la revendication 29, dans lequel la 
verification de I'objet de donnees a valeur stockee 
temporaire, sur la base de la valeur de graine, pen- 
dant une tentative de rachat ulterieure effectuee par 

le dispositif d'utilisateur (16), comprend la verifica- 15 
tion d'une sequence de nombres pseudo-aleatoire 
retournee a partir du dispositif d'utilisateur (16), ba- 
see sur lavaleurde graine etsurune valeurde I'heu- 
re courante du systeme de rachat. 

20 

31. Procede selon la revendication 27, comprenant en 
outre la verification de I'objet de donnees a valeur 
stockee temporaire a un second systeme de rachat 
(14) en utilisant un protocole de rachat a securite 
reduite en comparaison avec la verification initiale 25 
de I'objet de donnees a valeur stockee au premier 
systeme de rachat (14). 
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